The World Wide Web (WWW) provides access to a vast amount of information. At times, some information is accessed much more frequently than other information. At other times, information that was frequently accessed previously becomes less frequently accessed. For example, when a hot news story is first published on the WWW, many users may request the Web page featuring the story. As the story becomes older and other stories are published, the Web page may be requested less frequently. Eventually, the Web page may be requested seldom if at all.
Similarly, a company may announce a new product and post information on its Web site about the product. Initially, many users may request Web pages regarding the product. These requests may follow a certain pattern each day. For example, during morning working hours, requests for Web pages regarding the product may spike. Later in the day, requests for the Web pages may decrease. At night, relatively few requests for the pages may be received.
A company may place information on a Web page for a variety of reasons. For example, it may place information on Web pages to attract potential customers, inform employees, or establish a presence on the Web. When a user is required to wait too long for a Web page to be served, however, the user often loses interest and decides to visit other Web sites or pages. Responding too slowly to Web requests may be harmful for sales, decrease worker productivity, or give a company a bad image.
The ability to cache dynamically generated content has become an increasingly popular an important topic for businesses that wish to find and easy and economical way to scale their ability to serve data. While many vendors have a solution that enables them to cache dynamic content requested via an HTTP GET request, the same cannot be said for content requested via an HTTP POST request. A POST request by definition within the HTTP 1.0 specification is an HTTP request that includes a body as part of the request (a payload). Additionally, the default handling of POST requests as defined in the HTTP RFC (RFC 1945) states that POST requests are uncacheable. As such, cache engines are not designed to cache POST requests. According to RFC 1945, one of the main reasons that POST requests are uncacheable is because the application has no way of knowing that the server would return an equivalent response on some future request.
As such, the general assumption is that the queries will be widely varied (within the scope of the data/URL supplied in the POST request line) to the point where caching the results will provide little to no benefit. It is also an assumption that the data returned is frequently changing (also making it undesirable for caching).
Therefore, unless the request is a GET request, the data retrieved by the request will not be cached. There are an increasing number of situations, however, which go against the normal assumptions concerning POST requests and the dynamic data they return. It may be the case that while the response to a POST request is returning data that will in fact change later, it is known that it will be good for a certain extended period of time (for example, 24 hours). It may also be the case that POST requests are being utilized because the data required to obtain the desired result was too much to fit into a URL, and thus the additional space afforded by POST requests was necessary. In these situations and others, it may be beneficial to utilize the functionality of content caches to speed up transactions or to allow efficient scaling of applications. What is needed is a way to cache content requested by a POST request.